米国社会では、1960年頃から社会でのコンピュータ利用が進んだ。当初は、大型コンピュータの利用は科学技術計算が主体であった。しかし、直ぐに事務計算分野でも、小型コンビュータや中型コンピュータを利用して、企業内・組織内での様々なデータ処理を高速に実施する例が増加した。事務系の計算では、複雑な計算はないが、比較的単純な計算を大量なデータに対して実施する例が一般的であった。

事務計算では、従来は企業内で、人手によって実施されていた計算を、コンピュータに置き換える例が多く、人手で記入した帳票のデータをコンピュータに入力して処理をするのが一般的であった。事務処理のデータでは、帳票のデータが記入された日付など、日付データが重要であり、人手で記入された帳票にも日付が記入されている。その日付は、4桁で表されている西暦年号の下2桁を2桁の数字で、月を1から12の2桁の数字で、日付を1から31の2桁の数字で表す例が多かった。全体では、日付は、6桁の数字で表すことが一般的であった。

コンピュータによるデータ処理に変わっても、日付の表記は変わらなかった。このことは、1960年の1月1日であれば、600101と表記するのである。これは、人手で帳票を記入するのに手間がかからなかったからである。この方法は、事務計算を行うプログラムでも踏襲され、コンピュータで日付を処理する場合の方法として、標準的なものとなった。しかし、このことが将来大きな問題を起こす原因となった。2000年の1月1日は000101となり、1900年の1月1日と全く同じ表記になるからである。

問題は、こりような日付の処理がプログラムの至る所に散在していることである。当時のプログラマは、日付の処理が必要になると、自分が作成しているプログラムの中に、その処理を行う部分を書き込んだのである。今日のプログラマは、そのようなやり方が、プログラムを変更しなければならなくなった時、その日付処理の計算を探し出し、その処理の仕方を理解したうえで、必要な修正を加えなければならず、手間がかかることを理解している。今日のやり方では、日付処理は、全体に1か所だけに集約するのが普通である。

当時のプログラマ達は、誰も40年先の将来まで、自分達が、今、書いているプログラムが使われ続けることはないと思っていたのである。しかし、プログラムは、一度、使われるようになり、それが企業内に定着すると、今度は、それを新しいプログラムに変えることが難しくなる。それは、一般のプログラムの利用者にとって、新しい使い方になれなければならないと言う、苦労を強いるからである。

この事情は、個別の企業で作られたプログラムだけの問題ではなく、コンピュータを動かすために使われる基本ソフトウェアにも当てはまる。基本ソフトウェアでも、年月日によって動きを変えなければならないことも数多くある。その場合にも、6桁の数字で年月日を表すやり方は、ごく普通に使われていたのである。

1980年代も終わりに近づき始めた頃、基本ソフトウェアの開発や保守を担当していた技術者の間で、2000年の1月1日になったら、コンピュータが1900年の1月1日であると誤って認識して、大きな問題が発生するかもしれないという問題が議論され始めた。彼らは、古いプログラムの中身を理解して、問題なく変更を加えることの難しさを知っていたからである。

特に、日付の処理は、プログラムの至る所に散らばって存在している。その処理を見つけ出して、ひとつひとつ正しく変更してゆくことは、膨大な数の技術者と時間が必要になるのである。各企業、各コンピュータメーカは、1990年代の始め頃から、本格的にこの問題を担当するグループを設置して、プログラムの変更と、修正で新しい問題が発生しないことを確認することとした。

クリントン政権でも、この「2000年問題」を無事に乗り越えることが、米国社会の安定的成長のために必要不可欠であるとして、米国内の全ての企業組織に対して、1998年までにプログラムの変更を完了し、1999年には、2000年1月1日になったことを想定した、全国一斉の試験を実施する計画を発表した。

このように周到に準備された2000年問題であったが、2000年1月1日が来ると、最も早いニュージーランドで、クレジットカードの処理で問題が見つかり、システムはすぐに停止となった。その問題の解決には、8時間ほどを要したが、イギリスで1月1日が始まった頃、システムは正常に復帰し、世界的なパニックには発展しないで済んだ。日本国内でも、いくつかの問題が報告された。